\documentclass[12pt,a4paper,twoside]{report} %aggiungere openright

% % % % % % % % % % % % % % % % % % % % % % % PACKAGES
\usepackage[italian]{babel}
\usepackage[latin1]{inputenc}
%\usepackage{natbib}

\usepackage{fancyhdr} % libreria per impostare il documento

% libreria per indentazione all'inizio dei capitoli
\usepackage{indentfirst} 

% libreria per inserire grafici/figure
\usepackage{graphicx}

% libreria per utilizzare font particolari ad esempio \textsc{}
\usepackage{newlfont}

% per inserire testo da non formattare ect, tipo codice
\usepackage{verbatim}

% per url
\usepackage{url}

%\usepackage{pslatex} % fonts
%\usepackage[T1]{fontenc}
\usepackage{concmath}

% impostano i margini
%\oddsidemargin=40pt \evensidemargin=30pt

\begin{document}

%\include{sommario}

%\include{introduzione}

%\include{chap2}

\section{Aspetti Implementativi}
\subsection{Strutturazione del codice}
\subsubsection{Packages}
Il codice \'{e} strutturato in 6 differenti packages, per permettere al meglio la divisione dei ruoli e delle classi. Questi package sono:
\begin{itemize}
\item \textbf{unibo.lsb.communication} - al suo interno ci sono tutte le classi Java che permettono di realizzare le comunicazioni tra i vari processi e nella fase di registrazione al server.
\item \textbf{unibo.lsb.exception} - contiene 2 classi, una che estende l'eccezione base per aggiungere alcune utili informazioni per il progetto, e un'altra che contiene alcune costanti utilizzate all'interno del codice.
\item \textbf{unibo.lsb.graphic} - questo package contiene tutte le classi che permettono di creare la grafica o che vengono utilizzate dalle finestre per fornire informazioni sullo stato di avanzamento del gioco.
\item \textbf{unibo.lsb.logic} - in questo package troviamo tutte le classi che realizzano la logica vera e propria del gioco, dunque le regole, gli oggetti che vengono utilizzati durante una partita e le classi che permettono di realizzare i giocatori.
\item \textbf{unibo.lsb.server} - in questo package ci sono le classi che realizzano l'unica parte centralizzata del progetto, ovvero il server di registrazione.
\item \textbf{unibo.lsb.tokyo} - questo package \'{e} composto da un'unica classe, il cui scopo \'{e} quello di far partire effettivamente il gioco aprendo la finestra principale.
\end{itemize}

\subsection{Diagrammi}
\subsubsection{Diagramma delle classi}
\subsubsection{Diagramma degli stati}
\subsection{Scelte implementative}
In fase di progettazione, e quindi successivamente in fase di sviluppo, abbiamo deciso di fare un uso abbondante ma mirato del design pattern Singleton, questo poich\'{e} abbiamo alcuni oggetti che devono essere acceduti da diverse parti del codice senza dover essere ricreati tutte le volte, in quanto contengono informazioni importanti valide per tutta la durata del gioco.

Alcuni esempi di questo utilizzo sono:
\begin{itemize}
\item \textbf{unibo.lsb.logic.PlayerSelfSingleton} - lo scopo di questa classe \'{e} quello di mantenere un'istanza comune e unica che contiene tutte le informazioni sul giocatore, come ad esempio il nome all'interno del gioco, l'IP dal quale si sta giocano e l'avatar attraverso il quale si \'{e} riconosciuti durante il gioco stesso.
\item \textbf{unibo.lsb.graphic.GameTableWindowSingleton} - questa classe mantiene l'istanza della finestra principale di gioco. Tutti gli aggiornamenti grafici, come ad esempio l'aggiunta di penalit\'{a}, la rimozione di giocatori, il passaggio di turno, vengono notificati all'utente usando questa classe per reperire la finestra attualmente visualizzata, e agendoci poi in modi diversi a seconda della notifica da eseguire.
\item \textbf{unibo.lsb.communication.InformationSingleton} - questa classe mantiene un'istanza unica e comune di due importanti oggetti del nostro gioco, che sono:
	\begin{itemize}
		\item Game
		\item PlayersTable
	\end{itemize}
L'oggetto di tipo Game contiene tutte le informazioni sul gioco prima che questo sia iniziato, come ad esempio la lista dei giocatori e il nome del gioco stesso, mentre invece la PlayersTable contiene le informazioni sul gioco in corso, quindi il numero di penalit\'{a} di ogni giocatore, il turno corrente e cos\'{i} via.
\end{itemize}

\subsection{Reazione ai crash}
Il nostro progetto resiste al crash di n-1 giocatori, anche contemporaneo, fino ad eleggere il vincitore.

Abbiamo cercato di creare processi il pi\'{u} possibile paritari fra loro, infatti il nostro leader \'{e} sempre colui che ha il turno attuale.

Quando parte il gioco, ogni giocatore fa partire un polling verso il giocatore immediatamente successivo a se stesso. Ogni 0,2 secondi controlla che questo giocatore sia vivo e che non abbia superato il numero massimo di penalit\'{a}, e in caso negativo procede a compiere alcune operazioni descritte di seguito.

Tutte le volte che un giocatore viene trovato in stato di crash o eliminato, viene chiamato il metodo \textit{reactOnDeadPlayer}, che si preoccupa di notificare il nuovo stato del giocatore a tutti i partecipanti, e nel caso in cui che quel giocatore fosse il leader, anche il turno.

Abbiamo preferito controllare non solo lo stato di crash, ma anche quello di massima penalit\'{a}, per il fatto che un giocatore che viene eliminato dal gioco \'{e} pi\'{u} propenso a lasciarlo. In questo modo, noi anticipiamo questo possibile comportamento modificando il polling facendolo passare al giocatore successivo.


\end{document}